[レポート]みんなの考えた最強のデータアーキテクチャ #datatechjp

モダンデータスタック(MDS)

#データ分析

#モダンデータスタック

#dbt

#Fivetran

#Snowflake

さがら

2022.11.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

さがらです。

11月8日20時～22時に、datatech-jp(データエンジニアリング関係のコミュニティ)主催でみんなの考えた最強のデータアーキテクチャというイベントが開催されました。

本記事はこのイベントのレポートブログとなります。

イベント概要

※connpassより引用

datatech-jpで集ったデータエンジニアが、それぞれみんなの考えた最強のデータアーキテクチャを紹介し合うという夢のような企画が実現しました！

たくさんの新しいプロダクトが群雄割拠する現在、モダンデータスタックなどという言葉も登場しています。

今こそ、どんなプロダクトを選び、どのようなデータ基盤を作れば、効率的にやりたいことが実現できるのか。

5人の猛者からおすすめの構成をご紹介いただきながら、参加者のみなさんとも一緒に考えていく時間としたいと思います。

おまけ：当イベントの応募者数

このイベントですが、なんと開始前の11月8日19時50分の段階で1224人の方が登録をされていました…

データアーキテクチャというテーマに絞った上で、かつ一つのコミュニティのイベントでここまでの人数が集まるイベントは早々無いと思います！それほど、データアーキテクチャへの関心が高まっているのかもしれませんね。

スピーカーの皆様

ぼくのかんがえる最高のデータ分析基盤

登壇者

ぺい（近森淳平）氏

内容

誰のための基盤か？
- 機械学習のための基盤
- …と当初は考えていたが、全社(Zucks社)向けの基盤を考えることにした
対象データ
- 多種多少なデータがある（でっかいJSON）
- ８億レコード/日のデータ量
背景
- 社内に２つの基盤があった「データ分析基盤(BigQuery)」と「レポーティング基盤(Redshift)」
- しかし、基盤が分かれていることで、２つのDWHの内、片方にしかないデータなども存在してしまうようになった
BigQuery、Redshift両方の強みを持ったDWHはないか？
- Snowflakeが行けるよ！by菱沼氏
SnowflakeがRedshiftより優れているところ
- コンピューティングとストレージが完全に分離している
SnowflakeがBigQueryより優れているところ
- S3にあるログをそのままSnowflakeに取り込める
- 課金体系がウェアハウス(コンピューティング)実行時間課金
出来上がったもの
- 下図参照

dbtでETL？？
- ログを１時間毎にSnowflakeのExternal Stageからデータを取り出して、Snowflakeにロードする
- この処理では冪等性を担保し、データの変換処理は一切しない
- 他の選択肢も検討したが、COPYコマンドはかなり頑張る必要あり、External Tableはエラーが発生、Snowpipeはログファイルの数を減らさないとコストが見合わない、などの課題があった
オーケストレーション
- AWSのStep Functionsを使用
Snowpipeも使っています
- バッチロードだと１時間でも１回のため、すぐにデータを見ることができない。データがS3に入ったらすぐに見たいケースにSnowpipeを採用
- オブジェクト数課金になるので、コストが見合うならば基本はSnowpipeで良いと思う
Fivetranも使っています
- Auroraからのロードに使用
- ちょっとした管理画面のデータとの連携などに使用
- 一方で、広告データなどレコード数が多い大量データについてはコスト面なども考慮し、Fivetranは採用していない
Snowflake上でのdbtを用いたTransform
- ロードしたデータをモデリングするところに、dbtを使用
- モデリング手法は、基本的にディメンションモデリング
今後の展望
- BigQueryとRedshiftに乗っている運用を少しずつSnowflakeへ
- より使いやすい基盤にするため、開発しやすさを向上させる
- elementaryなどを使って、データ傾向の監視もしたい
感想
- ２ヶ月くらいでこの基盤は作れた！

もしなんの制約もなくデータ基盤を作れたら私はこうする

登壇者

菱沼雄太氏

内容

今日の内容について
- 普段手を動かせないフラストレーションの結晶
普段のお仕事でしていること
- 「JP1を使ってください」「EMRをDatabricksにしてほしい」などお客様からの要望は様々…
- 今日は特に制約なしで、自分の好きにデータ基盤を構築できた場合の話をしたい！

エンタープライズな会社の雰囲気
- 会社中からデータ基盤が集まってくる
データ基盤を構成する要素
- データウェアハウス
- データトランスフォーム
- ビジネスインテリジェンス
考えたデータ基盤
- 下図参照
- シンプルこそ一番！

Fivetran
- とにかく楽。データインジェストに技術力を要求していない
Snowflake
- 全体的に１００点満点
- ぶっちゃけサポートも良い（裏側の設定変えてくれたり、自分たち用のパッチを当ててくれたり）
dbt
- もはやdbtなしでは仕事したくない
BI
- 菱沼氏は、「BIはなんでも好きなものを使えばいいじゃん派」
機械学習
- 機械学習をしろ！DO ML
- Spark系の資産を活かし、機械学習をするには、Databricksが良い

データカタログ
- OpenMetadataが熱い、毎月リリースされている
- Alationもめっちゃよさそう、次に検証したいプロダクトNo.1

ガバナンス
- Immuta入れよう、アクセスポリシー地獄が少しでも楽になりますように…
- ImmutaはAlationからメタデータを引っこ抜ける

One more thing...
- モデリングは標準化された手法を使うのが良い
- DataVaultブチ込めばOK
- dbt使いつつDataVault採用したい➟dbtvault
- DataVaultは設定ベースで自動化だ！➟vaultspeed

実用的なデータ分析基盤について(個人的に思うところ)

登壇者

みっつ氏

内容

話す内容
- 0からデータ基盤を構築してみての概念的な話がメイン
実用的なデータ基盤とは？
- 様々な要求に対して素早く対応できる
- 技術的負債を少なくして品質を高く、チームの開発モチベーションを保つことが必要
- 結果として、「使い勝手がよく、プロダクトに貢献できるデータ分析基盤」を実現したい
様々な要求へ素早く対応できる
- 「値がおかしくなった」「データの形式が変わります」のような要求にサッと応えられる状態
品質を高く(技術的負債を少なく)保つ
- 「よくありがち」に流されない仕組みにすること
- 品質を犠牲にしないで、素早く出せる仕組みをつくる。犠牲にされた品質が手直しされるチャンスは永遠に来ない
- 人手を増やさなくても、短期間で作れる仕組みにする
チームの開発モチベーションを高く保つ
- リリース後の不具合が少ないこと。リカバリなど無用なストレスがなく、スムーズに開発が進むこと
- 建設的な議論が活発に起こること。心理的安全性が高いこと
- この実現には、システム運用アンチパターンをなくしたり、ドキュメントやWikiをちゃんと整備して情報格差を作らないことが必要と考えている
これまで
- 下図のスライドの赤字がクリティカルなボトルネックだった
- TreasureDataは今でも使っている

これから
- モダンデータスタックを活用する
- Snowflakeを中心としたアーキテクチャ

DevOps
- 開発スピードをあげていきたい
- ローカル開発環境は全てコンテナ化している。コンテナを起動するだけで、開発環境ができるため、新メンバーであってもオンボーディングのあとすぐに開発に取り掛かることができる

チーム内で好評な取り組み
- 話し合う機会の確保。定例、1on1、リリース後の振り返り
- こまめにdocs作成。ステークホルダーとのMTGの議事、実装前の設計事項、こまめにdocs化
- MDSの活用・アンチパターンの排除

落とし穴にハマりまくった僕のデータ基盤

登壇者

ゲンシュン氏

内容

これまでの経歴
- フロントエンジニア➟新卒エンジニア採用責任者➟QAエンジニア➟PM➟データ基盤の整備をすることに（実は、本イベントで登壇されているみっつ氏の後任としてデータ基盤を整備することになった）
現状のアーキテクチャ
- 下図を参照

超初期フェーズ
- 下図参照
- 良い点：冪等性が担保されていたため、ミスったら作り直すで大丈夫だった
- 課題：分析のためにカラム付与が多く、データマート層がキメラ化していった

terraform移行フェーズ
- 良い点：人に権限を持たせずにデプロイや実行が出来る。terraform applyの差分表示も嬉しい
- 課題：一部機能がDB移行することに伴い、ダウンタイムゼロで乗り切るため地獄のテスト祭りがあった

dbt移行フェーズ
- 良い点：過去の経験から仕様がすぐに変わるだろうと感じていたため、満点のアーキテクチャを目指さなかった
- 運用上意識したこと：既存の基盤と並走してダウンタイムゼロを目指した、並行運用はとても良かった

品質担保フェーズ
- データ基盤は、本当はデータを見るための基盤なので、運用面を減らしたかった
- このために、testを厳し目に実装することを意識した（意図しない謎の重複や謎のNULLの発見にもつながった）

まとめ
- その時にベストな選択をして段階を踏めたことで、dbtなどのツールの良さを感じることが出来たと思う

データ組織の最強(?)アーキテクチャ

登壇者

隅田敦氏

内容

なぜ組織のアーキテクチャを考える必要があるか？
- コンウェイの法則：システムはそれを設計する組織の構造を模倣したものになる
- 逆コンウェイの法則：逆に望ましい技術アーキテクチャを導くような組織を作ろう！
- この逆コンウェイの法則に則った、現在の取り組みを本日は紹介
これまでの組織アーキテクチャ（株式会社ナウキャストで何が起きていたか）
- ナウキャスト社は、利活用の進んでいないビッグデータ「Alternative Data」が保有側・利用側の双方に活用されるためのプラットフォームを提供している
- データエンジニアが主役となる組織であると言える、文字通りデータがプロダクトなので
- データに対する深いドメイン知識も求められる
これまでのチーム体制
- データソースごとに１つのチーム（１～５人）が形成されてきた
- １つのチーム内でインフラ～パイプライン～データ分析を一気通貫で行う組織構成
これまでのチーム体制での課題
- システムの品質向上に時間をかけられない。テストやドキュメントが存在しない、ETLジョブの監視が不十分、といった状況であった
- 特定のチームで上手く出来た改善が他のチームに横展開できない。他のチームにニーズがあるのか不明の上、仕組みを汎用化するインセンティブもない
- 複数のデータの掛け合わせができない（サイロ化）。各チームごとにサイロ化して育っていったシステムが出来てしまった
最強？のデータ組織アーキテクチャ
- 各チームで共通で必要となる開発を行う「Platform team」を作った
- スケーラビリティのために、DWHは統一する。
- 現在、DWH、ETL基盤、インフラ管理、は動くものが出来ている。現在CI/CD基盤に取り組んでおり、その後にデータ分析基盤に取り組む予定

DWH
- 単一のDWH上でSSOTを実現しつつも、computeは分離しておく。これはSnowflakeが優れている
- 適切な権限管理体制を仕組み化。データを消すなどの危険性の高い処理はAdminのレビューが必須
ETL基盤
- dbtを中心に構築
- 機械学習などのSQLで出来ない処理向けにAirflowも構築
CI/CD基盤
- GitHub Actonで定義。構築した内容は各チームに配布予定
データ分析基盤
- マネージドなNotebook環境を作りたい
インフラ管理
- IaCで管理している

結局どうしたら最強になれるの？データアーキテクチャディスカッション

オーガナイザーであるKT氏と、発表をされた5名のスピーカーによる「最強のデータアーキテクチャについてディスカッション」と「Q&A」もありました。

結局、どれが最強なの？
- 結果としては、Snowflakeやdbtが多くの発表で採用されていました
- この業界は５年経ったらぜんぜん変わるから、最強の追求に終わりはない（具体例として、５年前はdbtは世に全く広まっていなかった）
- データ基盤は組織によって最適解が本当に変わる。聞いたものをそのまま適用して最適、ということはない
運用面での課題や意識していることってある？
- 局所最適化するのではなく、どれだけ水平展開できるか、一般化できるか、が大事。これが出来るアーキテクチャが望ましいと思う
- 運用は下手すると地獄が待っている。運用の死＝プロジェクトの死
- クラウドでなかった時代は泥臭い仕事ばかりで、誰もやりたがらないような仕事だった。しかし、昨今はクラウド化により運用負荷が下がり、すごい効率化がされてきている
- FivetranやAirbyteなど、とにかくデータをDWHに入れてから考えられるようになって、運用負荷が大幅に減ったと思う。データレイクだと、S3やGCSの中身がカオスになってしまうことがあるので…
社内の他システムやプロダクト周りのアップデートをデータ基盤上でどれだけ追従していますか？（Slackの会話やプルリクエストから、察して対応していることも多いので…）
- データ基盤が下手するとプロダクトの足を引っ張ってしまうので、データエンジニアがこの点はとにかく頑張るしかない
- 出来る限り「運用の自動化」が大事、DevOpsのレベルで検知できることが理想
- ある意味、プロダクトのアップデートをデータ基盤側で無視することも一つの手として考えられる。データ基盤にプロダクトのアップデートが反映されていないことを突っ込まれたら、都度プロダクト開発者とやり取りを行って、対応していく
人いないって嘆くんじゃなくて、少数精鋭でできるようにしないとダメ
- データエンジニアのチームは、１人で色々行うことも多い。DWHのサービスが安定稼働していて信頼できることは非常に重要。DWHはデータエンジニアのパートナー
Snowflakeについて
- 少数のメンバーでも始めやすいDWH
- 権限周り(Role base access control)もわかりやすい
データ基盤やっててこれ見つけたらダメだよね、みたいなのあります？
- データマートを作ってと言われて作ったが、そのデータマートが使われた回数が１ヶ月に１回だけだった
- データをダウンロードされた後にExcelで魔改造される（特にひどい場合は、レポートに値を直接入力…）。逆に言うと、末端のExcelで魔改造がされていないということは、適切なデータ基盤が作れていると言える
- データに価値があるのではなくて、データがエンドユーザーにどう使われているかを知って、そのためのアウトプットを作ることが大事（例：レポートが欲しいのではなく、実際はSlackで通知が欲しかっただけ）
- カラム名一緒なのに、入っているデータが違う。入っているデータが同じなのに、どんどんRenameされてしまって別名のカラムが増えてしまう
データエンジニアの心得：新しい技術を常に学び、柔軟に考え、実行しよう。みんなで一緒に前に進もう
- 今後も、このような会を定期的にやっていきましょう！！